1. Field of the Invention
The present invention relates generally to managing performance in a network, and more particularly, to systems and methods for managing real-time performance between a bounded number of peers in a peer-to-peer environment that includes an unbounded number of peers.
2. Description of the Related Art
Many prior art approaches have been used to allow large peer-to-peer groups to communicate. A highly scalable, distributed hash-table overlay is typically used to provide logical links between members of the peer-to-peer group. By way of example, a commonly used highly scalable, distributed hash-table overlay is known as Chord such as described in “Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications,” by Stoica et al, (August 2001), In the Proceedings of AGM SIGCOMM 2001, San Diego, Calif. and also published at: http://pdos.lcs.mit.edu/chord/. The typical highly scalable, distributed hash-table overlay provides the ability to have a large peer-to-peer group that has a substantially unlimited number of peers (e.g., an unbounded peer group). The overlay also provides a look-up capability to look up hashed objects (i.e., resources) and identify which peer is publishing a particular the hashed object.
Peer-to-peer systems and applications are distributed systems without any centralized control or hierarchical organization (i.e., not client-server-based systems). The software required to participate in the per-to-peer environment that is running on each peer is substantially equivalent in functionality. The features of typical peer-to-peer systems include redundant storage, permanence, and selection of nearby servers, anonymity, search, authentication and hierarchical naming. The core functionality in most peer-to-peer systems is the efficient location of data items (i.e., objects). Typical per-to-peer overlay systems support one primary function: that of mapping a key to a respective peer.
FIG. 1A shows a typical peer-to-peer system 100. The peer-to-peer system 100 includes several nodes 112-124 in a first grid 102. Nodes 112-124 are peers because they are coupled together via grid 102. Nodes 112, 116, 118, 124 are also members of respective neighboring grids 104, 106, 108, 110. In operation, each of the peers 112-124 publish their presence (e.g., the availability of their respective resources) to each of the other peers on the grid 102 via the communication channels provided by the grid. The grid 102 is typically referred to as a universal grid (i.e., UG). While the grid 102 is shown as a two-dimensional grid for ease of illustration and discussion, it should be understood that the term “grid” could include more than two dimensions.
Nodes 130 and 132 are not directly connected to the UG 102 and therefore are not peers to all of the nodes 112-124. Nodes 130 and 132 are indirectly connected to UG 102, through respective peers 116 and 124. The presence of each of the peers 112-124 can also be published to nodes 130 and 132 through respective peers 116 and 124. In this manner, node 132 can discover and find the resources of peer 114. Node 132 can also form a direct link 134 to peer 114 to provide a more direct access to the resources of peer 114. The direct link 134 allows the both peers 114 and 132 to directly access the resources of one or both of the peers 114 and 132. The direct link 134 can also be thought of as a separate grid containing just two peers 114 and 132. Once the direct link 134 is formed, then one or both of the peers 114 and 132 can disconnect from their respective grids 102 and 110.
FIG. 1B shows the UG 102 and two fully connected grids (FCG) 126 and 128. In an FCG, direct links are formed between each of the peers in the FCG and each other peer in the FCG. The links between each of the peers in the FCG are shown as lines connecting the peers together. By way of example, in FCG 126, links are established from each peer 114, 116, 120 to each other peer in the FCG 126. Similarly, in FCG 128, links are established from each peer 114, 112, 122, 124 to each other peer in the FCG 128. Each peer member of an FCG receives a notification of all the resources available in all of the peers in the FCG. The notification is received in all of the peers in the FCG when the peers join the FCG.
FIG. 1C is a flow chart of the method operations 180 of locating a peer on the grid 102. With reference to FIGS. 1A-1C, in an operation 182, a first peer (e.g., peer 122) can join the UG 102 to search for and locate resources that may be provided by one of the other peers 112, 114, 116, 118, 120 and 124 that are already connected to the UG 102. In an operation 184, a desired resource is identified in a second peer (e.g., peer 114). In an operation 186, the first peer 122 joins the FCG 128 that includes the second peer 114. When peer 122 joins the FCG 128, the peer 122 forms direct links to each of the peers 114, 124 and 112 in the FCG 128. The method operations can then end.
Over time, more and more peers will connect in an FCG that has a particular object of interest. Unfortunately, as the number of peers in an FCG increases the number of direct links to each peer also increases. Recall also that each peer can be connected to multiple grids, even an infinite number of grids. As a result, the peers can often become overloaded. The operational overhead required by having too many direct links decreases the amount of processing time available to provide the desired access in a timely manner. As a result as the number of connections in an FGC increases, the ability of each peer member of the FCG to provide the direct access in an efficient and in a timely manner decreases. In view of the foregoing, there is a need for a system and method of managing the number of direct connections to each peer in an FCG.